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AMENDMENTS TO THE SPECIFICATION: 

Please amend the paragraphs beginning at page 1, lines 6, as follows: 




arrangements and a method in a third generation mobile telecommunication 

system and evolved variants thereof. In particular, the i»¥e»tioB-techi^^ 
relates to arrangements and a method for handling macro diversity in a UMTS 
Radio Access Network (UTRAN). 

BACKGROUND OF THE B>fVENT4QN 

Please amend the paragraphs beginning at page 2, line 9, as follows: 

FIG. 1 lUustrates a UTRAJM. The Radio Network ControUer (RNC) 102 is 
connected to the Core Network 100 that in turn may be comiected to another 
network. The RNC 102 is connected to one or more Node Bs 104 also denoted 
base stations via a transport network 106. The transport network 106 may e.g. 
be IP-based or ATM-based. The transport network nodes 108 are indicated with 
a "T" in FIG. 1. In an IP based transport network these nodes are IP routers. In 
an ATM based transport network the transport network nodes are AAL2 {ATM 
Adaptation Layer type 2) switches. The Node Bs 104 may be wirelessly 
connected to one or several User Equipments (UEs) 110 also denoted mobile 
terminals. A Serving-RNC (S-RNC) 102 is a RNC that has a Radio Resource 
Connection (RRC) connection with the UE 1 10. A Drift-RNC (D-RNC) 1 12 is a 




The-pdR 



technical field of the disclosure relates to 
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RNC that may be connected to a UE 1 10, but where another RNC 102, i.e. the 
S-RNC, handles the RRC connection with the UE 1 10. 

Macro diversity enables a mobile station to communicate with a fixed 
network by more than one radio link, i.e. a mobile terminal can send/receive 
information towards/from more than one radio port (or base station also 
denoted Node B). The radio ports (RPs) are spatially separated at distance from 
a short distance, e.g. between different floors in a building, (pico-cells) up to 
about some kilometres (micro- and macro-cells). As the propagation conditions 
between the mobOe terminal and the different RPs, ai-e different at the same 
moment in time, the resulting quality of the combination of the received signals 
Is often better than the quality of each individual signal. Thus, macro diversity 
can improve radio link quality. When a mobile terminal is connected to more 
than one base station simultaneously, the UE is said to be in soft handover. 

Please amend the paragraphs beginning at page 5, line 8 through page 
6, line 4, as follows: 

SUMMARY-&F4M IN\^ENTIQN 

The consumed transmission resources are reduced aeee r ding- -te -in one or 
more embodiments o f the present invention by distributing the macro diversity 
functionality to the Node Bs. A problem is then how to select which of the 
connected Node Bs that should be selected to perform the combining/ splitting 
function, also referred to as a Diversity Handover (DHO) function. These 
selected nodes are referred to as DHO nodes. The DHO nodes h a ve-te-be-are 
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selected out of those Node Bs that are able to perform the DHO functionality, 
I.e. out of those Node Bs that have been adapted Avith DHO functlonality-*i-ad 
eth«i^Heti©R«-ef#ie-pFee€irt4^ These nodes are referred to as DHO 

enabled nodes or macro diversity enabled nodes. 

H i e o bj e ct o f-tfae-presre Ht-inveritien is - t o so lve th e abo ¥e-st-ated:-prebleffh 




transmission savings in the UTRAN transport network, which translate into 
significant cost sa\angs for the operator. The transmission savings are realised 
through optimised location the DHO functionality. Thereby the redundant data 
transport is eliminated in the parts of the path, where data pertaining to 
different macro diversity legs of the same DCH would otherwise be transported 
in parallel along the same route. 

Another advantage ef 4iie-pFeseM-4«veritio»4s that i-t-feeilttates-feat-RNCs 
may be located in more central locations of the network (i.e. with less 
geographical distribution). T%eHH3ate:-i3^jbr-p<^ goal of the current common 
geographical distribution of RNCs is to limit the transmission costs for the 
parallel macro diversity legs. When this parallel data transport is eliminated, it 
becomes more beneficial for an operator to centralise the RNCs, e.g. by co- 
locating them with MSCs or MGWs. Co-locating several nodes on the same site 
results in simplified operation and maintenance, which also means reduced 
costs for the operator. 





r-taat- An advantage achieved 
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Please amend the paragraphs beginning at page 6, line 19, as follows: 

FIG. 4 illustrates the potential transmission savings in an example with 
cascaded Node Bs~aee0Fdfeg-4e-#ie~-B¥e«eH±-4nwH^^ 




FIG. 5 illustrates a scenario with a mobile terminal using five macro 



Please amend the paragraph beginning at page 7, line 1 , as follows: 

FIG. 10 shows the modified DHO node tree after the first step of the 
delay reduction method number 5 according to an embodiment-e#4be 
mveaiaee. 

Please amend the paragraph beginning at page 7, line 5, as follows: 

FIG. 12 shows the modified DHO node tree after the second step of the 
delay reduction method number 5 according to an embodiment~ef4fee 
i-Hventiea. 

Please amend the paragraph beginning at page 7, line 13, as follows: 

FIG. 16 shows the modified DHO node tree after the first step of the 
delay reduction method number 6 according to an embodlment-ef^the 
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Please amend the paragraph beginning at page 7, line 1 7, as follows i 

FIG. 18 is a flowchart of-eH(^f^fe^-Baettie4&«eeeBteig4^^ 
iaveBHaei^ : an example method . 



Please amend the paragraphs beginning at page 8, line 1 through page 
9, line 28, as follows: 

In the further description et#ie-p^Fes€ftt~-iftv«i-ifeH~coordm DCHs are 
not specifically treated. In the aspects that are significant to t he -^^feseat 
in vention a set of coordinated DCHs is treated in the same way as a single 
separate DCH. The DCHs of a set of coordinated DCHs use a common 
transport bearer and in an IP UTRAN the frames (of a set of coordinated DCHs) 
with the same CFN are included in the same User Datagram Protocol (UDP) 
packet. The special combining procedure for coordinated DCHs has been 
described above. Thus, omitting coordinated DCHs serves to simplify the 
description of th e-p-resea^}-^' • ^ i i .i. and makes the text more readable. Te 



ee e F dinate d--^€H-s^weuldbe-'eerM;epl^ally^^ 

H^ the - a i i^ ;' ■ attho ttgh-4 t - weul4 - &igmfi€^^^ c o m p li c at e t he t e x t . 

The fireseat-iByetttjoH- embodimentfs) may be implemented in a third 
generation mobile telecommunications system, e.g. in a UMTS, and in 
particular in the Radio Access Network (P^AN), e.g. a UMTS Terrestrial Radio 
Access Network, UTRAN. Such a system is illustrated in FIG. 1 and described 
above in conjunction with FIG. 1. 
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In order to reduce the required transmission resources, 




-it is proposed to distribute the macro diversity functionality 



from the RNC to other nodes for macro diversity configurations for which this is 
beneficial from a transmission point of view. These other nodes are typically 
Node Bs, but may also be other types of nodes, e.g. specialized Diversity 
Handover nodes. The potential transmission savings when the macro diversity 
is distributed to Node Bs are illustrated in FIG. 4. When a macro diversity 
configuration is established, or changed, it4s-fk=6%-y-eqttifed4eHsel^^ Node 
Bs that should be the Diversity Handover (DHO) nodes are first selected , i.e. 
the Node Bs that should perform the actual combining and splitting, before the 
macro diversity function is executed. The DHO nodes ba-ve-te -should be 
selected out of the available nodes that eetufirase -include DHO functionality, 
i.e. out of the DHO enabled nodes (typically DHO enabled Node Bs). In the 
examples below, the Node Bs and the RNC are used as DHO nodes, but it 
should be noted that other nodes such as specialized DHO nodes or logically or 
geographically distributed BNCs or future types of nodes Implementing parts of 
the RNC functionality also may be used as DHO nodes. In order to select the 
DHO nodes, the first step that is performed is to obtain topology information of 
the UTRAN transport network and how the nodes within the transport network 
are connected to the Node Bs. The topology Information may for example be 
obtaiaed in the topology map illustrated in FIG. 5. 

The topology information js-aeeerd-tHg te the present i nvention - can be 
obtained by developing a topology database. The topology database is adapted 
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to provide the RNC with the information the RNC needs in order to determine 
when distribution of the DHO functionality to the Node Bs is beneficial and to 
select the Node Bs to be involved. Hie topology database is first described for 
an Internet Protocol (IP) based UTRAN, including its general properties and 
ways to create it. Then, in a further section, the topology database for an ATM 
based UTRAN is described. 

The selection of the DHO node(s) ra^trires -implies that the RNC 
comprises or is adapted to retrieve Information about the topology of the 
UTRAN, both the UTRAN transport network and the Node Bs and RNCs, 
Different levels of richness of this information are conceivable. The choice of 
this level is a trade-off between the value it provides for the DHO node selection 
mechanism and the complexity it implies for the selection mechanism as well 
as the topology information retrieval mechanism. A certain level of flexibility of 
the richness of the topology information will be allowed in the further 
description of the DHO node selection. 

However, the topology information with a basic level of richness 
eeawlses accordi ng t o the t-)r e sent invention , should include : 

A hop-by-hop route from the RNC to each Node B that is controlled by 
the RNC and possibly some Node Bs that are controlled by neighboring RNCs, 
wherein each router is represented by the IP address associated with the 
mterface that is used to forward packets in the direction of the RNC. The Node 
B is represented by one of its IP addresses, e.g. the one used for NBAP (Node B 
Application Part) signaling (or the primary IP address used for NBAP signaling 
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in case multiple IP addresses are used for NBAP signaling). If a neighboring 
RNC is included in a hop-by-hop route, it is also represented by one of its IP 
addresses, e.g. the one used for RNSAP (Radio Network Subsystem Application 
Part) signaling (or the primary IP address used for RNSAP signaling in case 
multiple IP addresses are used for RNSAP signaling). 



Please amend the paragraphs beginning at page 11, line 9, as follows: 

In addition to the f6€itHF«4-topology Information the RNC masfe -should b e 
manually or automatically configured with knowledge about the relevant Node 
Bs that are able to comprise DHO functionality, also referred to as DIIO 
enabled nodes. The DHO enabled nodes are at least constituted by the DHO 
enabled nodes controlled by the RNC, but in inter- RNS macro diversity 
configurations they may also include other RNCs and Node Bs controlled by 
other RNCs. It is also possible that the DHO enabled nodes may include other, 
yet non-existing, types of Radio Network Layer (RNL) nodes, e.g. specialized 
DHO nodes. The RNC is-FeqtttFed-te -should know one IP address of each DHO 
enabled node, preferably the IP address used for NBAP signaling (or RNSAP 
signaling in the case of an RNC). This IP address i&-r-eqtii-t^4eH -should , be the 
same IP address as is used to represent the node in a hop-by-hop route. The 
RNC may be adapted to use the list of DHO enabled nodes to include an 
indication of whether the node is DHO enabled or not for each node in the hop- 
by-hop routes. 
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Aee&F€llH^-4^e^iabedimeH4B-ef4^^ can 
be_four possible ways for an RNC to provision the required topology 
information: 

1. Through manual or semi-automatic management operations. When 
the UTRAN (including its transport network) is buUt or changed, the relevant 
topology information is configured in the RNC via O&M means. 

2. Via a Link state routing protocol. If a link state routing protocol, e.g. 
Open Shortest Path First (OSPF), is used in the UTRAN transport network, the 
RNC may be adapted to pailicipate in the routing protocol communication as if 
it were a router. However, assuming that the RNC does not have a router 
function (i.e. the IP forwarding function) it would not announce reachability to 
any network other HtetweFfe-than the site infrastructure LAN. Therefore, in 
practice, no node w^uM-ey-eF- ls likely to attempt to use the RNC as a transit 
node, a node that forwards traffic, i.e. a node that is neither the source node 
nor the destination node. Thus, through the routing protocol the RNC 
eempFiees- can include means for maintaining an up-to-date topology database, 
without being required to perform other router functions. 

Please amend the paragraphs beginning at page 12, line 12, as follows: 

4. By retrieving topology information from another RNC. However, this 
method is eftly-lea&iMe -more applicable in the inter~RNs case. 

The third of the above listed ways to provision topology Information, i.e. 
the traceroute mechanism, fegmfas-ar-is further-detailed-desej^ptie H described . 
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Since the destination nodes, I.e. the Node Bs, ai*e not arbitrary nodes in the 
network, they may be prepared for the traceroute messages. This allows the 
traceroute program to work slightly differently from ti-aditional traceroute 
programs (although a traditional traceroute program would work too). A future 
IP based UTRAN will assumedlv presumably use IPv6, but for completeness an 
RNC traceroute program variant for IPv4 is also described. 

Please amend the paragraph beginning at page 15, line 6, as follows: 

When IPv4 is used the Time Exceeded ICMPv4 Message and the 
Destination Unreachable ICMP\'4 Message do not have to comprise more than 
28 octets of the invoking packet. That is, there i^ niay be room only for the IP 
header and the UDP header of the message from the RNC, which means that 
there is no point to include information in the UDP payload (unless the 
information is intended for the target Node B). The RNC traceroute program 
then has to work as traditional traceroute programs. That is, for each of its 
sequentially sent messages, it increases the destination UDP port number by 
one. The RNC is also required to store the destination address, the destination 
port, the hop limit and the time of sending for each message that it sends. 

Please amend the paragraphs beginning at page 16, line 14, as follows: 

To improve the stability of the traceroute delay measurements, the 
traceroute messages could be sent on high priority bearers, but the response 
messages from the Node B shetrid -is preferred to be sent on the same type of 



-11- 



1367500 



AMENDMENT 

U.S. Application No. 10/584,467 



Atty. Docket No.: 4208-38 
Art Unit No.: 2617 



bearer as the ICMP messages in order to provide a delay measurement (for the 
last hop) that can be compared with the delay measurements for the other 
hops. However, whether high priority bearers are used or not several traceroute 
measurements sfeyald -can be averaged in order to provide high quality delay 
measurements. The RNC could calculate the averages by repeating complete 
sets of traceroute messages or by repeating each traceroute message in a set. 

Running a number (e.g. 3-5) of traceroute measurements (i.e. sets of 
traceroute messages) towards each base station in the RNS periodicaUv such as 
every 24 hours would enable the RNC to maintain a reasonably up-to-date 
topology database with reasonably accurate link delay metrics, while Incurring 
an insignificant load in the transport network. The traceroute measurements 
shetrid-i s pre f e r red to , be spread out during a period of low traffic load, e.g. 
during night-time. 

Please amend the paragraphs beginning at page 19, line 22 through 
page 20, line 4, as follows: 

The mechanism that the RNC Is adapted to use in order to select the 
DHO node(s), i.e. the node(s) where the splitting and combining will be 

performed, is(are} the same whether optimized NBAP and RNSAP signaling is 
used or not. T-he-An, object of the DHO node selection mechanism aecordii %4e 




or more accumulated metric for the aU the macro diversity legs. According to 
one embodiment of the present invention, such an accumulated metric Is a 





-is to select the DHO nodes in a way that minimizes one 
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generic cost metric. According to a further embodiment this cost metric is put 
together with the condition that for none of the resulting data paths is the 
resulting path delay allowed to exceed a maximum delay value defined for the 
UTRAN. 

In the typical scenario, a DCH is first established with a single leg, i.e. 
without macro diversity. When a second macro diversity leg is added, the RNC 
selects a DHO node for these two legs and redirects the existing data flow if 
necessary (i.e. unless the selected DHO node is the Node B of the first leg or the 
RNC itself. When a third leg is added, the RNC fe-^qtiired to can rerun the 
DHO node selection process from scratch, since the addition of the third leg 
may affect the selection of the first DHO node. Hie RNC also has the choice to 
let the third leg go aU the way to the RNC (without trying to find a better DHO 
node) in order to not to affect the previous DHO node choice and to avoid the 
signaling involved in redirecting the existing flows. The same (i.e. rerunning the 
DHO node selection process from scratch or terminating the new leg in the 
RNC) applies to subsequently added macro diversity legs. 

Please amend the paragraph beginning at page 23, line 9, as follows: 

A retrieved hop-by-hop route is represented by a list of IP addresses (the 
IP addresses of the intermediate routers and the destination Node B), 
accompanied by a number of metrics for each hop. The IP address of the RNC 
i& -can be omitted, since it Is not needed for the DHO node selection process. 
The metrics may include one or both of a delay metric and a generic cost metric 
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(based on arbitrary criteria). The metrics may be asymmetric, in which case 
one set of metrics is supplied for each direction of a link, or symmetric, in 
which case the same set of metrics is valid for both directions. In the Olustrated 
example the metrics Include both a symmetric delay metric and a symmetric 
generic cost metric according to one embodiment of the present Invention. 
Table 1 shows the information that could be included in the route information 
that the RNC retrieves in the example scenario (i.e. the scenario depicted in 
FIG. 5). 

Please amend the paragraph beginning at page 28, line 8, as follows: 

The algorithm used for selecting a DHO node corresponding to a certain 
branching node is simple. Starting from the branching node the RNC is able to 
accumulate the generic cost metric In each direction (i.e. in the direction of 
each branch in the orlgmal route tree including the uplink) from the branching 
node until a DHO enabled node (or the end of the path) is found. (If asymmetric 
generic cost metrics are used, the generic cost metrics ha6-4» should b e the 
accumulated roundtrip from the branching node to the found DHO enable node 
and back. If synmietric cost metrics are used it suffices to accumulate the 
generic cost metrics In one direction.) The RNC does this by using the original 
route tree— not the simplified one. The DHO enabled node that was found with 
the smallest accumulated generic cost metric is selected as the DHO node 
corresponding to the concerned branching node. If the branching node is itself 
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a DHO enabled node, it will of course be the selected DHO node, since it is 
obviously the best choice and the accumulated generic cost metric will be zero. 

Please amend the paragraph beginning at page 29, line 15, as follows: 

Returning now to the DHO node selection example based on the example 
scenario in FIG. 5, the DHO nodes corresponding to the identified branching 
nodes will be selected as follows. Since sjuimetric generic cost metrics are used 
in this example, the cost metric is accumulated in only a single direction 
between a branching node and a potential DHO node. The DHO node 
corresponding to branching node R7 is NB4, for which the accumulated generic 
cost metrics from R7 is 4. All the other DHO enabled nodes in the route tree 
have greater accumulated generic cost metrics from this branching node. 
Similarly, the selected DHO node corresponding to the branching node R5 is 
NB3, for which the accumulated generic cost metrics from R5 is 4. The selected 
DHO node corresponding to the branching node R4 is NB3 again, for which the 
accumulated generic cost metrics from R5 is 7. The selected DHO node 
corresponding to the branching node R2 is NBl, for which the accumulated 
generic cost metrics from R2 is--4_l . 

Please amend the paragraph beginning at page 32, line 14, as follows: 

When the DHO nodes are selected, the last step before instructing the 
UTRAN nodes to establish the route tree including the selected DHO nodes is to 
check that the maximum allowed transport delay between a Node B and the 
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RNC is not exceeded. To do this, the connections in the DHO node tree are 
mapped onto the original route tree to form complete hop-by-hop routes. FIG. 9 
illustrates this for the DHO node selection example based on the example 
scenario in FIG. 5, i.e. the DHO node tree of FIG. 8is^ 8 is mapped on the route 
tree of FIG. 6. The resulting data flows are shown with the thicker arrows in 
FIG. 9. 

Please amend the paragraphs beginning at page 36, line 1 , as follows: 

If either Dnew-path-oL or Dnew-patii-uL exceeds the maximum allowed delay in 
the transport network {or a slightly lower delay threshold to provide a safety 
margin), the concerned path amst- should b e changed. There are different ways 
to do this with different levels of complexity (and performance). Ideally the DHO 
node selection should be restarted with new conditions to arrive at a new 
result, possibly with entirely or partly new DHO nodes. The goal should be to 
achieve data paths with acceptable delays with as small increase as possible in 
the overall accumulated cost metrics compared to the first DHO node tree. 
However, another Important goal is to keep the algorithm simple and 
computation efficient. Therefore the DHO node selection is preferably not 
restarted. Instead the concerned data path is modified in order to decrease its 
delay down to an acceptable level. 

g%e-One way to modify the data path is to remove one or more DHO 
nodes from the path, until the path delay is smaller than the maximum allowed 
value. By removal of a DHO node from a path is meant that the concerned data 
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flow bypasses the DHO node. The removed DHO node may remain in the path 
(if it is included in the original route of the Node B of the path), but its DHO 
functionality is not applied to the concerned data flow. If the data flow had to 
make a detour to reach the DHO node, the DHO node will not remain in the 
path after its removal. 



Please amend the paragraph beginning at page 38, line 15, as follows: 

In several of the delay reduction methods the RNC Hjsed s t o e atcuiat e 
calculates the potential path delay reduction (in terms of delay metrics) and/or 
cost Increase (in terms of the generic cost metrics for the whole DCH) that 
would result from the removal of a certain DHO node from the path. 

Please amend the paragraph beginning at page 52, line 22, as follows: 

A DHO Node Selection Algorithm for Cascaded Base Stations 

Sel€ietieft-Algef#iHH4eF-Gasead<ad-^ StatiQ Hjs4&-net-w^t4%fe4fae--seepe--9#--fee 
cl a i ms b u t is discl os ed to g i ve a betteF understand ing of the i n ven tion. 

Please amend the paragraph beginning at page 54, line 7, as follows: 

This algorithm fefj-m-ges-assumes that all the Node Bs in the sequence of 
cascaded Node Bs (or at least the radio active Node Bs in the sequence) are 
DHO enabled. If not aU the Node Bs in the sequence of cascaded Node Bs are 
DHO enabled, the algorithm may be extended with the following rule. If one of 



-17- 



1367500 



AMENDMENT Atty. Docket No.: 4208-38 

U.S. Application No. 10/584,467 Art Unit No.: 2617 

the radio active Node Bs, except the one furthest away from the RNC, cannot 
act as a DUO node because it is not DHO enabled, it is replaced (as a DHO 
node) by the next available DHO enabled node in the direction of the RNC. This 
next available DHO enabled node may be another radio active Node B, a non- 
radio active Node B, the RNC or even a future type of RNL node (e.g. a 
specialised DHO node). However, if the DHO node selection algorithm is 
designed to select DHO nodes only from the radio active Node Bs (and the RNC) 
then a non-radio active DHO node or a future type of RNL node cannot replace 
a non-DHO enabled radio active Node B as a DHO node. 

Please amend the paragraph beginning at page 56, line 22, as follows: 

When perfomiing the calculations of accumulated generic cost metrics, 
as described above in conjunction with the DHO node selection algorithm, for 
DHO node selection or for calculation of potential cost increase (as a result of a 
potential DHO node removal), it Hws^should be taken into account a 
fundamental difference between off-tree and on-tree DHO enabled nodes. For 
an on-tree DHO enabled node there will always be at least one data flow to and 
from the node's uplink interface, whether the node is selected as a DHO node 
or not. However, this is not the case for an oflf-tree DHO enabled node. If the 
off-tree DHO enabled node is not selected as a DHO node, there will be no data 
flow to or from the node in any direction. Thus, the data flows between an off- 
tree DHO node's uplink interface and the original route tree must be 
considered in the calculations, since it represents a cost increase resulting 
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from the selection of the off-tree node as a DHO node. Hence, an off-tree DHO 
enabled node is not likely to be selected, unless the accumulated generic cost 
metric from the corresponding branching node to the ofF-tree DHO enabled 
node is very low, like e.g. if the off-tree DHO enabled node Is a Node B that is 
co-located with the concerned branching node. 

Please amend the paragraph beginning at page 58, line 13, as follows: 

The Node Bs with DHO functionality preferably use an adaptive timing 
scheme to optimise the trade-off between delay and frame loss in the uplink 
combining. The timing scheme Is h owev e r not \vi feiR-the s cop e of th e preseet 

Please amend the paragraphs beginning at page 59, line 1, as follows: 

To establish a hierarchical macro diversity structure the selected DHO 
nodes aeed--te-sliould be instructed so that they know where to send spilt 
downlink flows and what uplink flows to combine. These DHO node 
instructions are based on the DHO node tree that is the outcome of the DHO 
node selection process. Every time the DHO node tree changes (due to addition 
or removal of macro diversity legs) all the affected nodes (both DHO nodes and 
non-DHO Node Bs| need new instructions. Instructions are also needed when 
DCHs are added or removed from all macro diversity legs. DHO nodes may also 
in accordance with an embodiment of the present invention need QoS 
instructions when DCHs are modified in a way that the QoS of their transport 
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bearers have to be changed. The affected nodes may range from a single to all 
Node Bs in the DHO node tree. No signaling is required when only the S-RNC is 
affected. 

In order to direct the DCH data flows in accordance with the DHO node 
tree the RNC imHet -should provide the involved Node Bs with the IP addresses 
and UDP ports (in an IP UTRAJM) or ATM addresses and SUGR parameters (in 
an ATM UTPIW) that they need to establish the inter-Node B transport bearers. 
If a transport network control plane protocol is used, the Node Bs handle this 
transport network control plane signaling between themselves and 
intermediate routers or AAL2 switches for inter-Node B transport bearers. 
However, there is no inter-Node B RNL signaling. 

Please amend the paragraph beginning at page 65, line 14, as follows: 

As stated above the RNC eaHBet-ma y not expUcitly instruct a DHO node 
of what destination IP address and UDP port to use for a transport bearer 
towards a hierarchically lower node. Actually, the RNC eaaaet -may not even 
explicitly inform a Node B that it has been selected as a DHO node and when 
the DHO functionality should be initiated or terminated. Instead a DHO 
enabled Node B ha&^e -can rely on implicit information in the data flows to 
trigger initiation and termination of the DHO functionality and to find out 
where to direct split data flows. 
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Please amend the paragraph beginning at page 66, line 8, as follows: 

The Node B dee& -may n ot receive any explicit QoS instructions for the 
new transport bccirer towards the hierarchically lower node, so if needed, the 
Node B feas-te- can derive the required QoS information from the DCH 
characteristics (which Is already known in the Node B) or copy the QoS class 
(e.g. DlffServe code points) used for the transport bearer of the same DCH 
towards the next hierarchically higher node. 

Please amend the paragraph beginning at page 67, line 21 , as follows: 

Thus, the RNC iHr-a<3eepda-Hee-witli4:4i«-pr-es^ 
include means for obtaining topology information comprising a hop-by-hop 
route from the RNC to each of its connected Node Bs and at least one metric for 
each hop in the route, and means for using an algorithm for selecting a DHO 
node. 
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